This invention relates to busses using a wired-AND protocol and, more particularly, to methods and apparatus for connecting devices in a bus system having multiple bus masters.
The I2C bus system is an electronic bus for carrying commands and data between compatible devices connected to the bus. The system was developed and marketed by Philips Semiconductor Corporation and is described in detail in the I2C Specification, revision 2.0, Philips Semiconductor Corporation 1995, which specification is hereby incorporated by reference in its entirety. In the I2C bus system, two wires, called a serial data (SDA) line and serial clock (SCL) line, carry information between the devices connected to the bus. Both the SDA and SCL lines are bi-directional lines, connected to a positive supply voltage via pull-up resistors as shown in FIG. 1 to form a xe2x80x9cwired-ANDxe2x80x9d configuration. For example, in the bus configuration 100 illustrated in FIG. 1, the SDA line 108 and the SCL line 110 are connected to the VDD supply line 102 by pull-up resistors 104 and 106, respectively. Other busses which use a similar protocol include the SMBus and Access. bus. Collectively, this type of bus system will be termed a xe2x80x9cwired-ANDxe2x80x9d bus system. The remainder of the discussion will focus on the I2C bus system with the understanding that the discussion applies to these other bus systems as well.
When the bus 101 is free, both the SDA line 108 and the SCL line 110 are pulled to a xe2x80x9cHIGHxe2x80x9d state by the resistors 104 and 106. The output stages of devices connected to the bus must have an open-drain or open-collector in order to form the wired-AND configuration. Two devices 112 and 114 are shown schematically in FIG. 1. Device 112 has a clock output stage which includes output transistor 116 which is connected across the SCL line 110 and ground 118. When a signal on the gate 117 of transistor 116 turns the transistor on, it pulls the SCL line 110 xe2x80x9cLOW.xe2x80x9d Clock signals on the SCL line 110 can be detected by means of buffer 120 whose output forms the xe2x80x9cclock inxe2x80x9d line 122.
Similarly, device 112 has a data output stage which includes output transistor 124 which is connected across the SDA line 108 and ground 126. When a signal on the gate 123 of transistor 124 turns the transistor on, it pulls the SDA line 108 xe2x80x9cLOW.xe2x80x9d Data signals on the SDA line 108 can be detected by means of buffer 128 whose output forms the xe2x80x9cdata inxe2x80x9d line 130. Device 114 also has a clock output transistor 132 and clock input buffer 134 and a data output transistor 136 and data input buffer 138 for communication with the SDA and SCL lines, 108 and 110.
Devices on the bus communicate by periodically pulling the SDA and SCL lines 108 and 110 LOW-producing data and clock pulses on the lines 108 and 110. In accordance with the I2C protocol, the data on the SDA line 108 must be stable when the clock line SCL 110 is HIGH. Thus, the HIGH or LOW state of the data line 108 can only change when the clock line 110 is LOW. Two unique situations arise, which situations are defined as START and STOP conditions. In particular, a HIGH to LOW transition on the SDA line 108 while the SCL line 110 is HIGH is defined as a START condition. A LOW to HIGH transition on the SDA line 108 while the SCL line 110 is HIGH is defined as a STOP condition.
Each device 112, 114 on the bus 101 has a unique address and can operate as either a data transmitter or a data receiver, depending on the function of the device. For example, an LCD driver is always a data receiver, whereas a memory can both receive and transmit data. In addition to being transmitters and receivers, devices can also be bus masters or slaves when performing data transfers. A bus master is the device that initiates a data transfer on the bus, generates the clock signals required for that transfer and terminates that data transfer. During this transfer, any other device to which data is sent, or from which data is received, is considered a slave. The bus master may transmit data to a slave or receive data from a slave. In both cases, the clock signals are generated by the bus master. Bus master and slave relationships are not permanent and depend on which device initiated the data transfer at a given time.
More than one bus master device can be connected to bus 101. Bus implementations with exactly one device capable of acting as a master are called single-master busses, while those with two or more devices capable of acting as bus masters are called multimaster busses. In a single-master bus system, the I2C protocol is very straightforward, with every transaction consisting of a START condition followed by one or more address and data phases, followed by a STOP condition. Thus, the START and STOP conditions frame all activity on the bus and hence define the duration during which the bus is busy.
In a single-master I2C bus, the only interesting error scenario that can present itself occurs when a slave device responds to an address or data phase with a negative-acknowledgement (NAK) response. A NAK response is represented as a HIGH signal level on the SDA line 108 during the acknowledge bit time, which is defined as the ninth clock pulse of any address or data phase. Since the I2C bus is a wired-AND configuration, a NAK response is equivalent to no response from a slave device. In the case of a NAK on an address phase, this may indicate that the slave device is busy and unable to accept I2C transactions at this time, that it is non-functional or simply missing.
Because NAK conditions happen only at well-defined points in a transaction, and because the interpretation of a NAK is straightforward, the response is not ambiguous. Most often, the bus master software may simply decide to retry a transaction that receives a NAK. The important observation is that NAK errors do not threaten the correct operation of the I2C bus itself; they affect only higher level protocol that is typically implemented in software.
Multimaster I2C bus implementations are dramatically more complex. The I2C protocol is essentially a carrier-sense multiple access with collision detection (CSMA/CD) scheme, which functions like an Ethernet system. However, unlike an Ethernet system, the I2C protocol lacks the higher layers of communication protocol that transform the Ethernet system into a reliable channel. As such, a large burden is placed on a multimaster I2C device. At every point in an I2C transmission, a bus master must be able to detect collisions with other bus masters and recover gracefully.
Some of these collision scenarios are particularly troublesome. For example, as described in the aforementioned I2C Specification, xe2x80x9carbitrationxe2x80x9d is the mechanism by which multiple bus master devices can drive the I2C bus simultaneously without causing data corruption. The basic arbitration mechanism relies on the open-collector nature of the bus; when two or more masters drive an address or data bit on the SDA line 108, a LOW value driven by one or more bus masters will always win out over a HIGH value produced by other bus masters. Thus, any bus master attempting to drive a HIGH value during a bit time (by not driving the SDA line 108 LOW and allowing the pull-up resistor 104 to keep the line HIGH), but sensing a LOW value during the same bit time, will recognize that a collision has occurred with another master driving a LOW value and relinquish the bus. However, if multiple bus masters are driving the same sequences of bits, then no collision will be detected until the bit sequences differ. Thus, it is possible that a bus master will detect a collision between itself and another master at some arbitrarily late point in a transaction, or even not at all.
Loss of arbitration is the simplest error type to handle from a protocol perspective because it automatically forces the losing bus master off the bus, as defined in the aforementioned I2C specification. In general, the bus master driving the numerically lowest message (address or data) will retain the bus, while those driving numerically higher bit sequences, i.e. with more 1""s will lose arbitration and be forced to retry their transactions after the current transaction completes.
The arbitration mechanism is defined in the I2C specification only for bus masters that collide while transmitting address and/or data bits. Since the bus masters are all in synchrony preceding the detection of the collision, the correct handling of the situation is straightforward, and the state of the bus (busy or idle) is well understood. Specifically, the bus is busy with the winning master(s) proceeding with the transaction. However, a collision between two masters where one is driving a data bit and the other is driving a START or STOP condition is, by contrast, not well defined by the I2C specification regarding how it should be handled.
This latter type of bus collision is more complex than a simple loss of arbitration. In this collision type, one bus master is transmitting or receiving a xe2x80x9c1xe2x80x9d bit, represented as a HIGH value on the SDA line 108, when another bus master drives the SDA line 108 LOW in the middle of the bit. This START or STOP condition is xe2x80x9casynchronousxe2x80x9d from the perspective of the bus master driving the data bit, because START and STOP conditions are allowed by definition only between address and data bytes, not on arbitrary bit boundaries. The I2C specification is unclear as to whether the bus master that detected this START/STOP condition should automatically stop driving the bus and record a loss of arbitration. Typically, this type of error is detected in hardware and reported to software as distinct from a normal loss of arbitration. In addition, when detected by a master while receiving bits, this type of error typically does not cause a master to stop driving the bus. Thus, when the error occurs, multiple masters are still driving the bus, but the START or STOP condition has abruptly truncated the transaction previously in progress. This error can occur if two or more bus masters drive identical transactions for some time, and then one of the masters issues a STOP or repeated START while the other attempts to continue the transaction with more data bytes.
This error can also indicate a much more serious scenario, which is that at least one master has become unsynchronized with the state of the bus (idle or busy) and has performed a transaction on top of one already in progress. This error can occur if noise has been introduced on the bus which has caused the SDA line 108 to experience a transient in the middle of a bit. Since the I2C bus system is an open collector bus with relatively weak pull-ups, and since some systems allow I2C devices to be xe2x80x9chot-pluggedxe2x80x9d onto the bus, such transients may occur.
The handling of this error is somewhat complex in that a bus master detecting this situation might retain ownership of the bus. In this case, the bus master must relinquish mastership of the bus either synchronously by driving a STOP condition, or by somehow resetting or reinitializing its I2C interface. In practice, it is unclear whether any bus master will be left driving a transaction. If the previous transaction in progress was aborted by all bus masters, then it is possible for the bus to become xe2x80x9chungxe2x80x9d, meaning that all bus masters having seen a START most recently (as opposed to a STOP), are waiting for someone to drive a STOP before they will attempt to reacquire the bus. Recovery from this state involves timeout timers and software specific to the I2C master""s hardware implementation.
The complexity associated with multimaster I2C affects both the hardware implementation of the bus master itself, as well as the software driver that works in conjunction with the hardware to perform well-formed I2C transactions. The added software complexity of multimaster I2C over single-master I2C takes the form of sophisticated error handling and bus recovery procedures. Furthermore, there are no published standards similar to the Ethernet system which specify how various protocol violations should be handled, or how higher level protocol layers should be used to add reliability to an unreliable I2C bus. As a result, a multimaster I2C bus system is an uncertain environment, with the total reliability of the bus only as good as the quality of the poorest bus master in the system. In addition, because the I2C bus system is perceived to be xe2x80x9ca simple, two-wire serial busxe2x80x9d, testing and verification of a bus master implementation""s multimaster hardware support is frequently not as thorough as needed, resulting in latent bugs. In many cases, these bugs cause data corruption and have no software workaround.
Therefore, there is a need for apparatus that could be used to construct a reliable multimaster I2C bus system.
In accordance with one illustrative aspect of the invention, xe2x80x9cfirewallxe2x80x9d apparatus is placed between a single bus master device and a multimaster I2C bus system. The firewall apparatus transforms all multimaster bus errors into simple NAK errors. Thus, a master that is isolated from the multimaster bus by the inventive firewall apparatus needs only to retry transactions that receive unexpected NAKs. All the complex multimaster issues, such as collision handling, transaction termination and bus recovery, associated with the actual error that occurred on the multimaster bus are handled by the firewall apparatus.
In accordance with one embodiment, when the master device on the single-master side of the firewall attempts to launch a transaction at a time when the multimaster I2C bus is busy, the firewall apparatus absorbs the address driven by the single bus master and then stalls the transaction until the firewall apparatus is able to successfully acquire and drive the address on the multimaster bus.
In accordance with another embodiment, the firewall apparatus stalls the single bus master transaction by controlling the SCL clock line and driving it low.
In accordance with another embodiment, when the master device on the single-master side of the firewall initiates a transaction, the firewall apparatus will automatically attempt to acquire the multimaster bus a predetermined number of times, thereby relieving the master device from attending to collisions and loss of arbitration which occur on the multimaster bus.
In accordance with yet another embodiment, the firewall apparatus is implemented by a programmed microprocessor which is controlled by a state machine program. In this embodiment, a START condition generated by the single bus master is detected by connecting the SDA line to an interrupt port on the microprocessor and running an interrupt service routine in response to an interrupt to detect that START condition.
In still another embodiment, the firewall software dynamically alters the operating frequency of the microcontroller depending on whether the microprocessor is communicating with the single master bus or the multimaster bus in order to meet timing requirements.